Programmable logic devices (“PLDs”) are a well-known type of integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (“FPGA”), typically includes an array of programmable tiles. These programmable tiles can include, for example, input/output blocks (“IOBs”), configurable logic blocks (“CLBs”), dedicated random access memory blocks (“BRAMs”), multipliers, digital signal processing blocks (“DSPs”), processors, clock managers, delay lock loops (“DLLs”), and so forth. As used herein, “include” and “including” mean including without limitation.
Each programmable tile typically includes both programmable interconnect and programmable logic. The programmable interconnect typically includes a large number of interconnect lines of varying lengths interconnected by programmable interconnect points (“PIPs”). The programmable logic implements the logic of a user design using programmable elements that can include, for example, function generators, registers, arithmetic logic, and so forth.
The programmable interconnect and programmable logic are typically programmed by loading a stream of configuration data into internal configuration memory cells that define how the programmable elements are configured. The configuration data can be read from memory (e.g., from an external PROM) or written into the FPGA by an external device. The collective states of the individual memory cells then determine the function of the FPGA.
Another type of PLD is the Complex Programmable Logic Device, or CPLD. A CPLD includes two or more “function blocks” connected together and to input/output (“I/O”) resources by an interconnect switch matrix. Each function block of the CPLD includes a two-level AND/OR structure similar to those used in Programmable Logic Arrays (“PLAs”) and Programmable Array Logic (“PAL”) devices. In CPLDs, configuration data is typically stored on-chip in non-volatile memory. In some CPLDs, configuration data is stored on-chip in non-volatile memory, then downloaded to volatile memory as part of an initial configuration (programming) sequence.
For all of these programmable logic devices (“PLDs”), the functionality of the device is controlled by data bits provided to the device for that purpose. The data bits can be stored in volatile memory (e.g., static memory cells, as in FPGAs and some CPLDs), in non-volatile memory (e.g., FLASH memory, as in some CPLDs), or in any other type of memory cell.
Other PLDs are programmed by applying a processing layer, such as a metal layer, that programmably interconnects the various elements on the device. These PLDs are known as mask programmable devices. PLDs can also be implemented in other ways, e.g., using fuse or antifuse technology. The terms “PLD” and “programmable logic device” include but are not limited to these exemplary devices, as well as encompassing devices that are only partially programmable. For example, one type of PLD includes a combination of hard-coded transistor logic and a programmable switch fabric that programmably interconnects the hard-coded transistor logic.
As is well known, a circuit design is compiled to run in the PLD. The compilation process converts the design as specified by a designer or programmer into the binary code that controls the PLD. For a microprocessor, the complier translates a programming language, for example the well-known “C” programming language, into microprocessor machine code. For a PLD, the design is compiled in several stages. It is synthesized, mapped, placed, and routed for providing a network list (“netlist”). Such a netlist may be provided to a bit generator, such as Bitgen, available from Xilinx, Inc., of San Jose, Calif. In response to a netlist, Bitgen generates a configuration bitstream which may be used for instantiating such circuit design in field programmable logic gates (“programmable fabric”) of a PLD. The configuration bitstream, as previously indicated, may be used to program programmable fabric to implement the circuit design with field programmable logic gates.
A bit generator, such as Bitgen, may include a design rule checker (“DRC”). A DRC in the context of a bit generator is not to determine whether layout rules have been violated, but rather is to determine whether the netlist has errors with respect to programming programmable fabric. For example, if there is a circuit which has an output that is supposed to connect to another circuit but does not, such a DRC may flag this hanging connection error. Another example of a design rule violation may be a network (“net”) not having a source or a net with two sources. Furthermore, there are other known types of errors to check for by use of such a DRC. A design with a design rule violation may give unpredictable results or may even damage the PLD. Therefore, in normal use, a bit generator or compiler will not create a bitstream or generate object code for a design with a DRC violation.
Compilers and bit generators may have options for unusual settings. These settings may override the safe operation of the software and generate output that may not function correctly. Optionally, a DRC of a bit generator may be forced to generate a configuration bitstream, even though one or more errors have been detected. Thus, for partial reconfiguration, when a user may be attempting to design just a portion of a circuit, such bit generator may be forced to generate this partial circuit standing alone without being connected to the overall circuit. Another option, rather than forcing bitstream generation, may be simply to turn off the DRC. Thus, designs with one or more errors may have configuration bitstreams generated for them. This may be useful in an experimental setting, where it is anticipated that errors will result from a check by a DRC. Accordingly, it should be appreciated that there are multiple uses for generating configuration bitstreams which have one or more errors as detected by such a DRC.
More recently, attempts have been made to reverse engineer configuration bitstreams. For example, a netlist may be provided to generate a bitstream that differs in a single feature from another netlist. By supplying both netlists to a bit generator and then subsequently comparing the two configuration bitstreams generated, information regarding the relationship of a configuration bitstream to a PLD may be gleaned. This tedious task of comparing configuration bitstreams in order to completely reverse engineer a PLD may take tens of thousands of bitstream generation cycles. However, with computer capabilities, such comparisons heretofore may have been performed within a reasonable time.
Unfortunately, reverse engineering in order to understand the function of each bit in a configuration bitstream may be used for unlawful pirating of a design. It should be understood that if a user is able to reverse engineer a configuration bitstream of programmable fabric, then the identity of associated circuitry of each bit becomes known. Accordingly, this may be used unlawfully or in violation of a license agreement to facilitate reverse engineering of the design of a user of a PLD.
Accordingly, it would be desirable and useful to provide means for deterring such reverse engineering of configuration bitstreams in order to deter piracy.